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The Communication Navigation and Networking Reconfigurable Testbed (CoNNeCT) is 
a NASA-sponsored mission, which will investigate the usage of Software Defined Radios 
(SDRs) as a multi-function communication system for space missions. A software- 
defined radio system is a communication system in which typical components of the 
system (e.g., modulators) are incorporated into software. The software-defined capability 
allows flexibility and experimentation in different modulation, coding and other 
parameters to understand their effects on performance. This flexibility builds i n h erent 
redundancy and flexibility into the system for improved operational efficiency, real-time 
changes to space missions and enhanced reliability/redundancy. The CoNNeCT Project 
is a collaboration between industrial radio providers and NASA. The industrial radio 
providers are providing the SDRs and NASA is designing, building and testing the entire 
flight system. The flight system will be integrated on the Express Logistics Carrier 
(ELC) on the International Space Station (ISS) after launch on the H-IIB Transfer 
Vehicle in 2012. This paper provides an overview of the technology, research objectives, 
payload description, design challenges and pre-flight testing results. 


INTRODUCTION 
The Space Communications and 
Navigation (SCaN) Office in the Human 
Exploration and Operations Mission 
Directorate at NASA Headquarters 
sponsored research and technology 
development in SDRs and 
communications architectures that 
missions could take advantage of over 
the next 20 years. In addition, other US 
agencies and aerospace communications 
companies have funded software defined 
radio research and technology 
development. Following the 
announcement of the Vision for Space 


Exploration in January 2004, NASA 
began to study and identify the benefits 
of moving to an SDR-based radio 
architecture. These benefits include 
multiple suppliers that could deliver to a 
common standard, greatly improved 
spacecraft communications architecture 
and the ability to better accommodate 
technology and operations evolution. 

By 2007only a few radio suppliers had 
developed and flight demonstrated 
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elements of SDRs ’ ’ and had evolved 
to designing, building and testing 
brassboard ground demonstrations of 



complete flight radio systems. The two 
missions that flew SDRs were Mars 
Reconnaissance Orbiter (MRO) 1 and 
Lunar Reconnaissance Orbiter (LRO) 2 . 
The inclusion of SDRs was more for 
hardware validation rather than for the 
utility of on-orbit reprogrammability. 
While the missions certainly were aware 
of the reprogrammable nature of the 
SDRs, reconfiguration was limited to 
essential reconfigurations or for 
demonstrations as part of the mission. In 
all cases, the missions did not plan to 
reconfigure to change operating 
characteristics of the radios. 

During this time, researchers were 
exploring various waveforms 
analytically and in laboratory 
experiments, and conducted a short 
duration flight demonstration aboard 
Space Shuttle Columbia 3 . SCaN 
program participants, observing this 
progress, knowing the potential benefits 
(e.g., risk mitigation for mission 
spacecraft), proposed a testbed attached 
to the ISS to provide the flight 
demonstration. The testbed gained a 
quick favorable reception within the 
predecessor to the SCaN program, and 
was formulated in 2006 and 2007 and 
initiated in 2007. 

FORMULATION OF THE SDR 
TESTBED 

Besides the few instances of SDRs in 
missions, SDRs were still a new, 
unproven technology. Field- 
Programmable Gate Arrays’ (FPGAs’) 
capacities were becoming sufficient to 
accommodate typical NASA waveforms 
and the US Department of Defense 
(DoD) was in the midst of developing 
SDRs for ground. A key research 
element underway at NASA was the 
development of the Space 


Telecommunications Radio System 
(STRS), a reference architecture for 
SDRs. 4 

During formulation discussions, the 
STRS team determined the importance 
that any flight demonstration project 
should 1) develop SDRs compliant to the 
STRS Architecture to advance its 
technology readiness level, reducing the 
risk for mission adoption, 2) fly multiple 
radios to demonstrate the applicability of 
STRS across platforms and 3) 
demonstrate capability envisioned by 
future missions. 

Studies in 2006 were conducted to assess 
technology needs of various NASA 
programs and several key elements were 
identified: Ka-band operations, 
adaptable S-band transceivers, on-board 
networking and future (e.g., L5) GPS 
signal assessments. These capabilities 
became the principal elements of the 
system. Since the radios would be 
reconfigurable and compliant with the 
STRS standard, the STRS team 
envisioned that multiple experimenters 
could use the system for a variety of 
experiments, thus as a testbed; 
experimenters could develop software 
for the radios for their own objectives, 
within the constraints of the overall 
system. 

To improve the utilization of STRS and 
provide sources of STRS compliant 
radios, multiple radios on the testbed 
were envisioned coming from both 
industry and NASA labs. This would 
provide an initial source of STRS radios 
for future missions. To contain the cost 
of flying multiple radios, NASA released 
a NASA Research Announcement 
(NRA) to develop and receive the 
industry provided SDRs. The NRA 



offered an opportunity to host SDRs on 
the testbed and provide time for the 
developers to access their SDR for their 
own experimental use. In return, NASA 
required that the proposer share the 
development cost of the SDR. After a 
competitive review and selection, both 
General Dynamics Corporation and 
Harris Corporation were selected to 
develop and deliver SDRs to NASA for 
the flight experiment. In addition, 
NASA’s Jet Propulsion Lab (JPL) was 
also funded to develop an STRS SDR. 
Thus, after the NRA selections, the 
testbed would host three SDRs, with GD 
providing an SDR for S-band, Harris 
providing a Ka-band SDR, and JPL 
providing a dual-band SDR of both S- 
band and L-band. 

REQUIREMENTS 

The requirements for CoNNeCT were 
derived from formulation objectives and 
were decomposed into specific Level 1 
requirements in the following five main 
groups: 

1. Use reconfigurable systems to 
validate different communications 
capabilities and advance the 
Technology Readiness Level (TRL) 
to 7 of laboratory SDRs, the STRS 
standard, proposed waveforms, 
access schemes, architecture flight 
software and operational concepts. 

2. Test technologies for Exploration 
Systems Mission Directorate 
(ESMD) Constellation (Cx) and 
other NASA mission directorates’ 
communications and networking for 
risk reduction. 

a. Lunar relay emulation 


i. Ka-band forward link and return 
links via Tracking and Data 
Relay Satellite System (TDRSS), 
at data rates representative of 
Lunar Relay and/or Lunar 
network capabilities up to 6 
Mbps forward and 25 Mbps 
return, transmitting up to 100 
Mbps internally and/or externally 
generated, using Single Access 
(SA) connectivity. 

ii. S-band and Ka-band capabilities, 
such as S-band low data rate 
links simultaneously with 
Ka-band high data rate links, 
utilizing multiple SDRs. 

b. S-band forward link and return 
links via TDRSS, including, at 
minimum, data rates at 72 kbps 
forward and 192 kbps return, using 
SA and Multiple Access (MA) 
connectivity. 

3. Demonstrate on-orbit SDR/STRS 
performance and operations from 
multiple suppliers. 

4. Conduct navigation experiments to 
include verifying tracking and 
performance of SDR-based GPS, 
tracking and performance of TDRSS 
Augmentation Service for Satellites 
(TASS)-augmented GPS and TDRSS 
tracking and ranging. 

5. Conduct communications and 
networking experiments to assess 
Delay Tolerant Networking (DTN) 
protocols, on-board routing and 
potentially other Constellation 
Command, Control, 

Communications and Information 
(C3I) concepts. 



The development of the lower level 
requirements was a combination of a top 
down decomposition and a bottoms-up 
capability-driven approach. The top 
down method was traditional, with the 
usual challenges and decisions on 
management of external requirements 
given the large requirements documents 
(e.g., ISS ELC). The radios were pre- 
selected (before the Level 1 
requirements baseline) and requirements 
were largely defined from prior 
specifications and capabilities. Hence, 
the level four and five requirements 
specifications were written, informed the 
Levels 1 (HQ/Program), 2 (System), and 
3 (Flight and Ground System) 
development and then were updated and 
expanded to capture the top down 
decomposition. This approach worked; 
however, this approach was not the most 
effective and is not recommended for 
future developments (Refer to Design 
and Development Challenges, below). 

DEVELOPMENT APPROACH 

The development approach for the flight 
and ground systems minimized the 
schedule and cost by optimizing the 
procurement approach including and 
combination of NASA internal work, 
Cooperative Agreements and standard 
procurements. Furthermore, the project 
minimized schedule and budget 
resources using a protoflight 
development approach. This approach 
included breadboards for most 
subsystems, an engineering model (EM), 
a flight model (FM) and no qualification 
models. The flight system consists of 
the structure (flight enclosure), three 
SDRs, the Radio Frequency (RF) 
subsystem, avionics, thermal control and 
the Antenna Pointing System (APS). 


The specific procurement strategy was 
as follows. Two of the three Software 
Defined Radios (SDRs) were developed 
using Cooperative Agreements, with 
General Dynamics and Harris 
Corporation providing approximately 
half the development costs. NASA JPL 
(teamed with L3 Cincinnati Electronics) 
provided the third SDR and RF 
subsystem including antennas. NASA 
Glenn Research Center (GRC) provided 
the structure, avionics, software, 
thermal, APS and system integration 
using in-house engineering, 
manufacturing and test capabilities and 
procurements. The JPL SDR software 
was developed by three NASA Centers 
with the intent to prove out the STRS 
paradigm for the S-band waveform: JPL 
provided the Operating Environment 
(OE) and Goddard Space Flight Center 
(GSFC) and GRC jointly provided the S- 
band TDRSS Waveform Applications. 
Finally, the mission operations required 
no significant procurement since existing 
GRC ISS operations capabilities were 
leveraged. 

To buy down development risk, 
subsystem breadboards and EMs were 
combined to create several testbeds to 
conduct the following testing: 

• Structural Test Article (STA): Flight- 
like primary structure in terms of 
mechanical form and fit; used to test 
and verify the random vibration 
loads using mass simulators for 
subsystems, buying down risk for the 
system. 

• Software Development Systems 
(SDSsl: Breadboard avionics and 
SDRs with ELC simulators (ISS 
interface) used to develop and test 
software. The project ultimately 
purchased the components to 



develop five SDSs, which enabled 
parallel developments and risk 
mitigation prior to testing on the 
Ground Integration Unit (GIU). 


risk items or those that were cost- 
prohibitive did not have spares. 
Additionally, elements of the EM SDRs 
had identical flight parts and provided 
alternative sparing opportunities. The 
avionics unit was a new higher-risk 
development and a spare unit was 
created; this helped later with system 
issues. For structures and thermal, 
sparing was also at the component level 
(e.g., fasteners). 



Figure 1: Software Development System 

Ground Integration Unit (GIU): 


Replica of the flight system using 
EM units that have the same function 
and very similar form and fit; it 
became the “workhorse” testbed 
used for software development and 
formal verification, communication 
system testing, dry run procedures 
prior to flight and mission operation 
procedures, training and tools. GIU 
was initially configured in a “flat 
sat” or table-top configuration to 
enable easy configuration update and 
was later installed into the STA 
enclosure to become as flight-like as 
possible. The GIU bought down 
significant risk prior to testing on the 
flight system and enabled parallel 
development given two robust 
platforms. 

To save resources, only limited flight 
spares to mitigate higher risks were 
included in the development. For the 
SDRs, RF and APS systems, sparing 
was done at the component level for 
long-lead electrical components; low 


Figure 2: Ground Integration Unit 

The overall project schedule from 
Preliminary Design Review (PDR) to 
Flight System Ship (ready) was about 
two years. This is about one year less 
than a standard development due to the 
protoflight approach, early development 
of the radios, and the continuous energy 
given by the team to complete the work 
quickly, without compromise to design 
and certification requirements. 

HARDWARE DESIGN 

The CoNNeCT flight system (to be 
called the SCAN Testbed on-orbit) is 
illustrated in figures 3 and 4. The 
testbed relies upon the ISS ExPRESS 
Pallet Adapter (ExPA) 5 to provide 
standardized structural, electrical and 
data interfaces with the ISS ELC, the 
Space Station Remote Manipulator 
System (SSRMS), and the Japanese 
Aerospace Exploration Agency (JAXA) 




Multipurpose Exposed Palate (EPMP) 6 . 
Among other items, the ExPA includes 
the active portion of a Flight Releasable 
Attachment Mechanism (FRAM), power 
and data connector panels, 
Extravehicular Activity (EVA) 
/Extravehicular Robotic (EVR) 
interfaces and the payload adapter plate. 
The ExPA serves as the foundation of 
the CoNNeCT flight system. 



Figure 3 - CoNNeCT flight system 



Harris UP/DN 
Converter 


Figure 4 - Flight system without ExPA and non- 
radiating panels 


so they will be discussed in a separate 
section. The following paragraphs 
briefly describe the remaining support 
subsystems. 

The mechanical subsystem provides 
structural support for the other 
subsystems; its design also allows 
thermal energy to be rejected to space 
via three radiating surfaces (starboard, 
ram and zenith radiators). The 
subsystem consists of a frame-and-panel 
flight enclosure, various mounting 
brackets, fasteners, and multilayer 
insulation on the two non-radiating 
exposed surfaces (wake and nadir 
shields). The mechanical subsystem 
accounts for 39% of the 339 kg flight 
system mass. 

The electrical subsystem receives a 
maximum of approximately 500 W of 
electrical power from the ExPA, 
conditions it and transfers it to the 
electrical loads in the system. Digital 
communication between subsystems and 
overall system command and control is 
also provided by this subsystem. The 
electrical subsystem is comprised of 
three primary subassemblies [avionics, 
TWTA power supply unit (PSU), and 
thermostat control assembly (TCA)] plus 
resistance heaters and the cabling 
interconnecting all of the subsystems. 
Functional interaction of the avionics 
portion of the electrical subsystem and 
other elements of the flight system is 
depicted in figure 5. 


On the ExPA foundation, the following 
five additional subsystems are integrated 
to form the flight system: mechanical 
subsystem, electrical subsystem, RF 
subsystem, APS, and SDRs. The SDRs 
are the principal reason for the testbed, 



Figure 5 - Functional interactions of avionics 
with other flight elements 


The avionics unit uses a 733 MHz 
processor and 64 GB of flash memory to 
operate the flight system. SpaceWire 
and MIL-STD-1553 buses are employed 
for command and telemetry as well as 
data flow. 

The RF subsystem consists of an RF 
plate subassembly, a traveling wave tube 
amplifier (TWTA), five antennas and 
interconnecting transmission cable and 
waveguide. The RF plate subassembly 
contains Ka- and S-band diplexers, a Ka- 
band isolator and attenuator and three 
coaxial transfer switches to route signals 
to and from different S-band antennas. 
Two low-gain S-band antennas and an 
L-band antenna are installed stationary 
with respect to the flight system. The 
medium-gain S-band antenna and the 
high-gain Ka-band antenna are jointly 
housed on an articulating arm, the APS, 
for pointing. The RF subsystem and its 
interfaces are graphically depicted in 
figure 6. Functional interactions of the 
RF subsystem are also shown in figure 5. 


KaHGA 



The APS is used to point the medium- 
gain S-band and high-gain Ka-band 
antennas for communication with the 
TDRSS. In addition to a launch restraint 
and thermal control resistance heaters, 
two other main subassemblies combine 
to complete the APS: the integrated 
gimbal assembly (IGA) and the gimbal 
control electronics (GCE). The IGA 
contains two rotary actuators - one each 
for local elevation and azimuth 
adjustment. The actuators in 
combination with the arm mechanism in 
which they are housed enable precision 
pointing of the antennas over a large 
viewing area. Restrained by physical 
hardstops to limit irradiation of ISS 
elements, the IGA rotation spans 174 
degrees in elevation and 76 degrees in 
azimuth. The resultant boresight sweep 
limits are shown in figure 7. This field 
of view allows the testbed to satisfy key 
availability requirements for monthly 
Tracking and Data Relay Satellite 
(TDRS) contacts. 



Figure 7 - Bor esight sweep limits 


Using a MIL-STD-1553 interface, the 
GCE provides the power, control and 
telemetry path between the IGA and the 
avionics subassembly. Position and rate 
commands are sent from the avionics 
software to the GCE which then 
translates and sends the appropriate step 
commands to the actuators. Optical 
encoders on each actuator provide 
position indication telemetry that is 
transferred through the GCE to the 
avionics. Because of the wide beam 
width of the medium-gain antenna, 
TDRS S-band links are easily 
established using open-loop pointing 
algorithms in the avionics software. 
However, for Ka-band communication 
with a TDRS, closed-loop control based 
on signal feedback from the Harris SDR 
is used to accurately point and track 
using the APS. 


SOFTWARE DEFINED RADIOS 

The SDRs are the technology core of the 
flight system, representing advancement 
in both SDR technology and the STRS 
Architecture. The three SDRs developed 
by Jet Propulsion Lab, General 
Dynamics and Harris Corporation each 
adhere to the functional diagram shown 
in figure 8. The functional diagram 
illustrates three key elements of each 
SDR: a general purpose processor 
module (GPM), a signal processing 


module (SPM) and a Radio Frequency 
(RF) Module (RFM). Each SDR is 
consistent with this type of architecture; 
however, specific implementations differ 
for each radio. 



Figure 8 - General SDR architecture 


The GPM contains the general purpose 
processor and associated memory 
elements for application processing and 
radio control. The STRS OE runs within 
the GPM to control the waveforms and 
other radio functions and platform 
services throughout the SPM and RFM. 
The GPM controls loading the waveform 
from persistent memory (e.g., 

Electrically Erasable Programmable 
Read-Only Memory or EEPROM) into 
the processor or FPGA as designed. 
Portions of the waveforms can run 
within the GPM or SPM and are 
abstracted from the underlying hardware 
by the STRS Standard. The SPM 
includes the hardware for the high speed 
signal processing performed in each 
radio, in this case, by Xilinx FPGAs. 
Clock management and distribution 
functions of the SPM are distributed 
throughout the SPM and other modules. 
Finally, the RFM contains the digital to 




analog (DAC) and analog to digital 
(ADC) conversion elements and signal 
conditioning circuits to the RF interface 
at the appropriate frequency. 

The software architectures are also 
similar among the three SDRs. Each 
conforms to the STRS Architecture 4 
software interface depicted in figure 9. 
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Figure 9 - STRS Software Architecture 


The STRS OE manages the functions 
within the SDR, including command and 
telemetry, inter-process communications 
among software elements, and control 
functions such as loading and unloading 
the waveforms from memory and 
executing the waveform. The key 
element of the software architecture is 
the application programming interface 
abstraction between the waveform 
application and the underlying hardware. 
User applications access the real time 
operating system (RTOS) of the 
operating environment through a 
Portable Operating System Interface for 
Unix (POSIX) interface and the 
waveforms access remaining OE 
functions through a set of application 
programming interfaces (APIs) defined 
by the STRS Architecture (STRS API). 
Once a user waveform application is 
loaded on a platform, the POSIX and 
STRS APIs provide the software 
interfaces to the underlying hardware. 


On the firmware interfaces within the 
FPGA, the STRS Standard calls out 
requirements for FPGA signal 
abstractions between the application and 
the platform hardware provided by the 
platform developer and certain 
documentation of abstractions for 
hardware resources (e.g., FPGA, DAC, 
ADC) available for future waveform 
developers. 

The flight SDRs each utilize a modular, 
stacked configuration and are shown in 
figure 10. 


JPLSDR GD SDR Harris SDR 



Figure 10 - Flight SDRs 


A summary of the SDR performance and 
design characteristics is shown in figure 
11 . 




SDR 

JPL 

GD 

Harris 

General 
Purpose and 
Signal 
Processing 
Modules 

66 MHz 

SPARC 

processor 

and two 

Xilinx 

Virtex II 

FPGAs 

60 MIP 
Coldfire 
processor 
and one 
Xilinx Virtex 
II Pro FPGA 

700 MIP 
Power PC 
processor 
and four 
Xilinx 
Virtex IV 
FPGAs 

RF Module 

Two (I/Q) 
10-bit 50 
Msps DAC 
and one 12 
bit 50 Msps 
ADC; S- 
band Duplex 
(2. 1-2.2 
GHz, 6 MHz 
tuning) and 
GPS receive 
at LI, L2, 
and L5 

S-band 
Duplex (2.1- 
2.2 GHz, 6 
MHz tuning) 

Two 12-bit 
300 MHz 
DAC and 
one 300 
MHz ADC. 
Ka-band 
(transmit: 

25.5- 25.7 
GHz, 225 
MHz 
tuning, 
receive: 

22.5- 22.7 
GHz, 50 
MHz 
tuning). 

Memory 

Units 

128 MByte 
SDRAM 
and 512 
MByte flash 

128 MByte 
SDRAM, and 
4 MByte 
EEPROM; 
also 1 MByte 
Chalcedonide 
RAM as 
experiment 

256 MByte 
SDRAM 

Operating 

Environment 

RTEM 
operating 
system; OE 
complies 
with STRS, 
vl.02 

Vx Works 
operating 
system; OE 
complies 
with STRS, 
vl.02 

Vx Works 
operating 
system; OE 
complies 
with STRS, 
vl.02 

Command & 
Telem 

MIL-STD- 

1553 

MIL-STD- 

1553 

SpaceWire 

Data Format 

Space Wire 

Spacewire 

SpaceWire 

Data Rate 
Class 

10’s Mbps 

10’s Mbps 

100’s Mbps 

Output 

Power 

Amplifier 

10W 

10W 

Ka 

convertor 
drives 40W 
TWTA 


Figure 11 - SDR Characteristics 


BUS SOFTWARE DESIGN 

The CoNNeCT SCAN Testbed avionics 
flight software works in conjunction 
with the software resident on the flight 
SDRs as well as ground software 
commands received via the interface 
with the ISS ELC. The avionics flight 
software is “class C” in accordance with 
NPR 7150.2 - NASA Software 
Engineering Requirements. A layered 
architecture is employed that separates 


SCAN Testbed application code from 
other layers such as hardware interfaces, 
component drivers, and the operating 
system. Using over 100,000 lines of 
mostly C++ code (comprised of third- 
party and in-house elements), the 
avionics flight software satisfies 66 
allocated requirements at the software 
subsystem level that decompose into 
additional lower-level software 
requirements. In operational mode, the 
flight software manages the following 
eight states: primary-path-ready, 
initialization, ready, experiment, 
maintenance, off-nominal, shutdown, 
and safe. The functions associated with 
the states can be grouped as command 
and control, housekeeping and telemetry, 
fault management, experiment 
management, timing, and interface 
management. To simplify the flight 
software design, all safety-critical 
commands are issued from the ground; 
the flight software processes cannot 
issue these commands independent of 
ground initiation. To maximize 
flexibility for future experiments, the 
flight software is designed so that 
updated versions of the software - 
including the kernel - can be uploaded 
on-orbit. 

EXPERIMENT OPERATIONS 

Once on-orbit, the CoNNeCT SCAN 
Testbed will be available to 
experimenters from NASA, industry, 
academia and other organizations. 

Based on announcement of opportunities 
offered by NASA, experimenters will 
propose investigations to conduct using 
the SCAN Testbed. Experiments will 
entail new software applications that run 
on the SDRs or within the flight 
computer (avionics) along with 
experiment specific ground hardware or 




software. The experiment software 
applications will demonstrate new 
communications signal formats (e.g., 
modulation, coding), networking (e.g., 
on-board routing and DTN) and 
assessment of navigation techniques 
based on Global Positioning Satellite 
(GPS) signals at LI, L2, and the 
emerging L5 GPS frequencies. 

Once a proposal is submitted to NASA, 
an Experiment Review Board will assess 
the objectives and advancements 
proposed and recommend experiments 
for use with the SCAN Testbed that 
meet the solicitation criteria. Once 
approved, experimenters will begin 
development of their new experiment 
application and ground hardware. After 
development has progressed beyond the 
design and initial development stage, 
experimenters will be provided access to 
the SDR and avionics breadboards and 
engineering models at NASA GRC to 
continue, refine and complete their 
waveform or avionics application 
development. When an experimenter 
completes their SDR application, the 
waveform will be tested for STRS 
compliance and verified for operation 
with the flight system. After verification, 
the application software will be 
uploaded to the flight system for on-orbit 
experiment operations. 

To conduct the on-orbit portion, 
experimenters will generally work from 
the Experiment Center at GRC working 
closely with the CoNNeCT Control 
Center. Experiment specific ground 
hardware will reside at the Experiment 
Center. The Experiment Center is 
linked to the Space Network (SN) 
Control Center where experiment data is 
exchanged with White Sands Complex 
(WSC) and transmitted to CoNNeCT via 


TDRSS. Experimenter hardware will 
send and receive data directly with the 
SCAN Testbed through the CoNNeCT 
ground system infrastructure. 

As shown in figure 12, experiment data 
links at Ka- and S-band exist between 
CoNNeCT and NASA’s TDRSS and 
WSC ground station or may use an S- 
band direct to ground link (not shown in 
figure). During pre-flight testing, 
simulators are used for the ELC interface 
and ISS command processing. 



Figure 12 - Experimenter-TDRSS Interfaces for 
Pre-Flight Testing 


ISS AND HTV INTEGRATION 

A standard ISS integration approach is 
used via the Johnson Space Center (JSC) 
Payload Integration Manager (PIM), 
with some extension of prior work since 
CoNNeCT is the first ELC payload 
installed on-orbit. The carrier physical 
interfaces are depicted in figure 13 and 
the HTV launch processing is shown in 
figure 14 (similar to Kennedy Space 
Center). The HTV delivers its cargo to 
the vicinity of the ISS where the ISS 
robotic arm operations conduct many 
transfers and installation. 










Figure 13 - ISS and HTV Carrier Interfaces 




I nternational Shipping Container 


SCAN Testbed in 
Launch Configuration 


Figure 14 - HTV Launch Site Processing 


DESIGN AND DEVELOPMENT 
CHALLENGES 

Numerous challenges occurred during 
design and development of the 
CoNNeCT flight system. Many of the 
difficulties were rooted in an 
unconventional method of requirements 
development. As noted earlier, level 4 
and 5 requirements existed (and 
hardware was even purchased) before 
level 1 , 2 and 3 requirements were 
adequately established. Some examples 
of requirements-related design problems 
are presented below. 

APS “Heritage ” Hardware 
When the APS was procured, the level 3 
requirements were underdeveloped, so 
the level 4 procurement specification 
was based mostly on what heritage 
hardware could be obtained to meet 


perceived cost and schedule constraints. 
A purchase order (not a development 
contract) was issued for an integrated 
antenna pointing system based on the 
actuators and gimbal control electronics 
(GCE) used on a previous NASA 
mission. The vendor had provided the 
actuators and GCE for the earlier 
mission, but the heritage integrated 
gimbal system was not built by the 
vendor; it was developed in-house at the 
Goddard Space Flight Center (GSFC). 
The CoNNeCT purchase order (PO) 
relied on the vendor to produce an 
integrated APS based mainly on the 
previous mission’s requirement set, 
which turned out to be inadequate when 
the level 3 requirements were completed 
and flowed to level 4. Asa result of the 
inadequate requirements and the lack of 
integration experience at the vendor (and 
partially due to the PO contracting 
mechanism initially chosen to save two 
weeks of procurement time), thirteen 
change orders (with cost and schedule 
growth of $3.3M to $6.5M and 15 to 23 
months, resp.) and intensive interaction 
with the APS vendor was required to 
finally produce a useful APS for 
CoNNeCT. 

Structural Redesign and Margin 
As discussed above, development of the 
SDRs was initiated by NASA 
Headquarters before the CoNNeCT 
project was fully established. As a 
result, structural and loads requirements 
were immature and were not adequately 
represented by the level 5 vendor 
specifications; the SDRs were 
underdesigned for the environments that 
would have given the best system-level 
optimization of primary structure. As a 
result, the system structural team was 
required to repeatedly craft their design 
around the SDR constraints. Multiple 





design iterations were needed with fairly 
high-fidelity numerical models to 
eventually demonstrate adequate 
structural margins. 

ISS ELC Co-development 
Because the ISS ELC was being 
developed at nearly the same time as the 
CoNNeCT flight system, the level 2 
ELC interface requirements were subject 
to serious perturbations after CoNNeCT 
tried to finalize level 3 requirements. 
When the ELC reduced its total payload 
28-volt power capacity, the CoNNeCT 
electrical team had to adopt a new basic 
architecture that included a 120-volt-to- 
28-volt DC-DC converter to power the 
TWTA. Because the addition was late in 
the development cycle, mounting surface 
space in the system was scarce and the 
new TWTA power supply unit (PSU) 
had to be located outside the primary 
flight enclosure. Inconvenient assembly 
constraints resulted due to the final PSU 
location. 

FRAM Non-linearity 
Simultaneous with learning that the ELC 
was reducing power availability, the 
CoNNeCT design team learned that a 
misunderstanding between JAXA and 
ISS caused the EPMP-to-FRAM 
interface to be improperly labeled. The 
H-II Transfer Vehicle (HTV) ICD with 
JAXA specified the launch loads at the 
interface between the EPMP structure 
and the passive FRAM. The ISS team 
had instructed that the launch vehicle 
interface was on the surface of the active 
FRAM. (JAXA installs the passive 
FRAM on the EPMP; the active FRAM 
is located on the bottom of the ExPA.) 
The passive FRAM is relatively stiff, so 
the JAXA specification could be applied 
to the passive FRAM surface with little 
error. However, the gap between the 


passive and active FRAM introduces a 
non-linearity in the loads transfer 
function; a translational non-linear 
uncertainty factor of 1.5625 and a 
rotational non-linear uncertainty factor 
of 2.0 were subsequently levied on our 
launch acceleration loads. An unclear 
interface definition caused the structural 
design team to have to restart their 
design cycle. 

The above examples are no surprise to 
the experienced space system design 
engineer. A major complicating factor 
early in the development was that 
relatively few people working the issues 
had significant space flight design 
experience. This was corrected by PDR 
with the introduction of very 
experienced leaders and engineers. 

ASSEMBLY AND INTEGRATION 

The CoNNeCT flight subsystems each 
had their own development challenges 
and associated schedule for completion. 
As a result the subsystems were not 
available for system integration at the 
same time. This impacted the nominal 
physical and analytical integration 
processes and the project developed 
revised implementation methods to 
enable forward progress on the system. 
As a result, CoNNeCT revised the 
system integration and test schedule to 
optimize it based on which elements 
were available to enable a given test 
activity. The following describe some of 
the top challenges and their resolution. 

System Integration Review 
NASA policy requires a System 
Integration Review prior to installation 
of flight subsystems. Since not all 
subsystems were available, this 
requirement was waived and an alternate 



process was developed. Each subsystem 
was subject to an Acceptance Review 
(AR) to verify the hardware and 
documentation and an Integration 
Review (IR) to verify the system was 
prepared for integration (physical, 
processes, etc.). Hence, the SIR intent 
was met via incremental ARs and IRs. 
This enabled the flight assembly to 
mature as soon as subsystems were 
ready. To preserve schedule, lower risk 
analytical products were completed after 
the physical integration. 

Avionics Unit 

Due to issues associated with the power 
filtering, digital interface and thermal 
control custom cards (five total), the 
flight avionics unit (the payload’s core 
processor) was delayed by months. The 
project recovered most of the schedule 
by installing the back-up avionics unit 
first, since it did not require 
environmental testing and was available 
six weeks sooner. This enabled critical 
software and communication testing to 
proceed on schedule, including TDRSS 
Compatibility. The flight certified 
avionics unit was installed prior to the 
first system environmental test. 

Antenna Pointing System 
As a result of the development issue 
explained above, the APS experienced 
significant schedule delays summing to 
approximately four months late on 
delivery. In anticipation, it was decided 
before CDR to create a dynamic 
simulator of this model to proceed with 
system vibration and thermal/vacuum 
(T/Vac) testing, which created schedule 
relief to complete APS delivery. 
Significant resources were used on the 
dynamic simulator for the IGA, since the 
structural dynamic models of simple 
geometries did not adequately simulate 


the loads from the APS back into the 
system. Further details are below in the 
environmental testing section. For T/Vac 
testing, the solution was simpler since 
the IGA base was the only element 
required to validate the thermal model. 

FUNCTIONAL TESTING 

The SCAN Testbed is a complex system 
of highly integrated analog and digital 
communication subsystems. Functional 
testing was frequently performed after 
assembly to demonstrate increasing 
levels of communication between 
subsystems and integrated avionics 
performance. Similar functional testing 
was performed before and after system- 
level environmental tests. Some 
problems were to be expected at the 
beginning of post-assembly integrated 
testing. However, three significant 
problems that were encountered (and 
ultimately resolved) were not expected. 
A short description of each problem and 
its resolution follows. 

Space Wire Cables 
As mentioned, the CoNNeCT flight 
system uses the SpaceWire standard for 
SDR-avionics data transfer and for 
command and telemetry on one SDR. 
SpaceWire is an established standard 
and is in use by other NASA, ESA and 
JAXA projects. The SpaceWire cable 
procured for the CoNNeCT flight system 
is from a major supplier and is 
representative of the cabling 
commercially available. However, 
because SpaceWire cable is less robust 
than typical aerospace cabling, the cable 
fabrication and installation techniques 
initially used on the flight system led to 
cables shorting to connector backshells, 
damage to inter- wire Teflon insulation 
and intermittent loss of data links 



between subsystems. Although not 
readily available in the literature, special 
fabrication, handling and installation 
techniques in use at the GSFC were 
employed to eliminate the undesirable 
performance. For example, figure 15 
shows the special foam padding and 
generous bend radius that was used 
when the cable was supported by tie- 
wraps so that the internal insulation 
between wires would not be 
compromised due to Teflon cold- flow 
over time. Dissemination of other 
special techniques to use with 
SpaceWire cable is planned for 
forthcoming publication. 



Figure 15 - SpaceWire Cable (blue) 


SpaceWire Firmware 
The SpaceWire board in the avionics 
unit was procured from a major 
commercial source. After uncovering 
performance issues in how the vendor 
implemented the combination of 
SpaceWire and PCI standards on the 
board, several attempts were made to 
correct the problem through changes in 


the vendor firmware. After four 
unsuccessful iterations, the fifth change 
yielded an acceptable firmware 
implementation that provided increased 
SpaceWire bus performance. 

Digital Input/Output Firmware 
A similar flawed firmware situation was 
encountered on the digital input/output 
(DIO) cards procured for the avionics 
unit - again from a major supplier of 
aerospace electronics boards. During 
integrated testing of the flight system, 
inadvertent power-on of subsystems was 
observed. Detailed bus-level 
troubleshooting revealed that, despite the 
avionics software correctly commanding 
the DIO state, within milliseconds 
additional bus traffic would cause the 
board to self-corrupt and change the set 
state to an uncommanded configuration. 
Working with the vendor, a corrected 
version of firmware was obtained (by 
replacing the FPGA and recertifying the 
cards at the subsystem level) and stable, 
reliable DIO performance was finally 
obtained. 

ENVIRONMENTAL TESTING 

After assembly and successful functional 
testing, the CoNNeCT flight system was 
subjected to system-level vibration, 
thermal-vacuum (T/Vac), and 
electromagnetic interference/ 
compatibility (EMI/EMC) tests. (Note: 
Acoustic certification was accomplished 
via analysis with launch provider 
concurrence.) As mentioned above, due 
to the delayed delivery of the APS, the 
vibration and T/Vac tests were 
conducted without the APS installed. 

For the vibration test a high-fidelity 
dynamic simulator, including simulated 
antennas, was constructed to provide the 
correct dynamic loads for critical 



subassemblies in the flight system. The 
simulator was designed and modal tested 
to show that the resultant loads imparted 
to critical subassemblies would be 
dynamically similar to within 5% on 
fundamental frequencies, 10% on 
higher-order frequencies, and 10% on 
Grins acceleration values with good 
modal shape correlation and good 
acceleration spectral density (ASD) peak 
and phase correlation. These design 
criteria were synthesized in the spirit of 
NASA-STD-5002 and ISS document 
SSP 52005D. In the T/Vac test, the arm 
of the IGA dynamic simulator was 
removed to enable more accurate control 
of the thermal boundary condition at the 
starboard radiator. (This would have 
been desirable even if the flight IGA had 
been available.) A GCE mass and 
thermal simulator was also fabricated 
and installed for the first two 
environmental tests (vibration and 
T/Vac). System EMI/EMC testing 
occurred only after APS (IGA and GCE) 
installation on the flight system was 
complete. Pre- and post-test system 
functional tests were performed to verify 
no adverse effects were introduced by 
system environmental tests. 

System vibration testing was conducted 
at the NASA GRC Structural Dynamics 
Laboratory. As defined in NASA-STD- 
7001, the project used a proto flight test 
approach with force-limited control to 
avoid over-test. Most subsystems were 
tested to maximum flight loads + 3 dB 
prior to system integration. The 
integrated test inputs for each of the 
three axes were as follows: x-axis 5.59 
Grms, y-axis 5.69 Grms, and z-axis 5.31 
Grins. Spectral representation of the test 
inputs showing predicted and actual 
force-limiting notches are shown in 
figures 16-18. 
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Figure 16- x-axis test input 



Figure 1 7 -y-axis test input 



Figure 18 - z-axis test input 

After system- vibration testing was 
complete, post-test functional checks 
were nominal. Post-test analyses 
concluded that the flight system was 
certified for random vibration loads. 

The system T/Vac test was performed in 
Vacuum Facility 6 at NASA GRC. 



During the test, the flight system was 
subjected to four mission-based thermal 
cycles at vacuum (less than 1 x 10" 6 torr) 
including hot (+45 °C) and cold (-15 °C) 
soaks and power-off/on demonstrations 
per the thermal system model 
predictions. Most subsystems were 
tested to six T/Vac cycles prior to this 
test. The flight system is pictured under 
test in figure 19. 



Figure 19 - Flight system in T/Vac 


During testing, thermal transition 
periods were accomplished more 
efficiently than planned, so the actual 
total test time was approximately 222 
hours (42 unpowered, 180 powered). 
Post-T/Vac functional checkout was 
completed successfully. The JPL SDR 
required more testing to allow 
calibration measurements since the 
TDRSS waveform was not part of 
subsystem testing. In the nine days of 
T/Vac testing, only four problem reports 
were filed. One of the four was 
eventually traced to a potential thermally 
induced hardware issue. 

Investigation of a different problem 
report uncovered poorly soldered 
connections on two boards within one of 
the SDRs. After T/Vac testing, the 
boards were removed from the still- 
installed SDR, reworked at the vendor, 
recertified by test and reinstalled. 
Because of the serviceable design 


configuration, the nature of the removal 
and reinstallation did not require retest at 
the system level. Analyses concluded 
that the flight system was certified for 
the mission thermal environment. 

The final system-level environmental 
evaluation was the EMI/EMC test. This 
test was conducted in the NASA GRC 
EMI laboratory. Test requirements were 
derived from ISS documents SSP 57003, 
SSP 57003-ELC, SSP 30237 and SSP 
30243. (Prior to system- level testing, a 
number of subsystem-level EMI/EMC 
tests were also conducted for risk 
mitigation.) As summarized in figure 
20, the system-level test addressed 
radiated and conducted emissions, AC 
and DC magnetic fields and radiated and 
conducted susceptibility. Five different 
flight system operational modes were 
configured during testing. The flight 
system is pictured in the EMI laboratory 
in figure 21. 
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Figure 20 - EMI/EMC Test Summary 



Figure 21 - System EMI/EMC Test 


During the three weeks of 2-shift 
EMI/EMC operations, three conducted 
susceptibilities were noted on the 





avionics unit and one conducted 
susceptibility was observed on an SDR. 
In all four cases, previous interface 
testing with the ISS ELC simulator 
showed the actual electrical transient 
characteristics to be less severe (and 
acceptable) than the EMI/EMC test 
conditions, so no modifications to the 
flight system were required. System- 
level testing additionally confirmed one 
expected conducted emission 
exceedance on the 120- volt power lines 
during initial power-on. Previous ELC 
simulator testing also showed actual 
integrated in-rush current would be 
acceptable for flight, so no flight system 
change was warranted. Radiated 
susceptibilities were noted on SDRs near 
radio operating frequencies; evaluation 
of the data showed this to be an expected 
condition given the EMI/EMC test 
levels. The actual on-orbit environment 
is not expected to present similar noise 
emitters. Flight system self 
compatibility was successfully 
demonstrated at the end of the 
EMI/EMC testing. 

Exceedances observed during EMI/EMC 
testing were evaluated and deemed to be 
of minimal impact to payload flight 
operations with acceptable risk. 

PERFORMANCE TESTING 

In addition to standard environmental 
tests for a typical flight system, users of 
NASA’s SN also conduct a 
compatibility test to assess performance 
and verify operations with both the 
TDRSS and WSC ground system 
hardware. A series of communications 
tests are conducted to measure aspects 
such as tracking and acquisition 
thresholds of the radios and link 
performance, and to ensure transmitter 


spectrum quality meets transmitter 
license requirements. 

There were two new aspects to the 
compatibility testing for CoNNeCT. 
First, as NASA’s first Ka-band TDRSS 
user, CoNNeCT exercised the new Ka- 
band compatibility test process and 
equipment. This test included verifying 
the operational service at WSC, 
including a high rate data path from 
WSC to GRC. These connections are 
shown in figure 12. Second, CoNNeCT 
is the first SN user flying SDRs. 
Compared to typical users having a 
command and telemetry link and a 
science data return link, the number of 
selectable configurations of the 
CoNNeCT’s SDRs combined with the 
multiple antenna paths proved to be a 
challenge during compatibility testing. 
With the current set of one launch 
waveform file for each SDR, CoNNeCT 
has over 100 different “waveform” 
definitions, each requiring a unique 
configuration code at WSC to identify 
the TDRSS service, data formatting, 
modulation and coding aspects of both 
the forward link from WSC to 
CoNNeCT and the return link from 
CoNNeCT to WSC. 

The TDRSS Compatibility Test was 
completed in three phases of 
approximately one week each to align 
with the subsystem test schedule and the 
system capabilities. Minor 
incompatibilities were uncovered during 
the first test phase, which were corrected 
through firmware updates and retested 
during the subsequent phase. This is an 
example of the value of the 
reconfigurable nature of the radios. The 
inability to modify the firmware would 
have resulted in performance 



degradations in certain operational 
modes. 

In addition to the TDRSS Compatibility 
Test, a second communications system 
test entailed verifying the gimbal motion 
open-loop and closed loop Ka-band 
pointing algorithm. For communication 
using the gimbal mounted, medium gain 
S-band antenna (and 36° for 3 dB 
beamwidth) link analysis indicates that 
pointing the antenna based on the 
ephemeris information of ISS and 
TDRSS is sufficient to close the link 
without fine pointing (i.e. open-loop). 
For Ka-band communications however, 
the link requires that the gimbal point 
the Ka-band antenna (1.6° for 3 dB 
beamwidth) using a closed loop pointing 
algorithm. The pointing algorithm uses 
a signal strength indicator from the 
Harris SDR receive waveform and 
moves the antenna along the antenna 
pattern gradient to maximize the 
received signal strength. Prior to testing 
with hardware in the loop, a detailed 
simulation was created that exercised all 
closed loop functions. This simulation 
was validated with actual hardware and 
now is a reliable tool to verify algorithm 
changes. 

The antenna pointing system test 
included the avionics (hosting the 
algorithm), the GCE, the gimbal, and the 
gimbal-mounted S-band and Ka-band 
antennas. 

The open-loop testing characterized the 
gimbal motion across each axis, and 
included measuring insertion loss 
throughout the rotary joint travel range 
and verifying the mechanical and 
electrical antenna boresight alignment. 
Closed-loop testing used a portable near- 
field range within the clean room and a 


source transmitter on a moveable 
platform to emulate the TDRS. Figure 
22 depicts the closed loop test setup with 
the TDRS emulator cart (foreground) 
and the flight system (60 ft away in the 
background). The cart hosts a planar 
scanner system with a waveform 
generator and transmit horn attached. 

The cart follows a predetermined path on 
the floor and combined with the planar 
scanar motion, simulates the ISS 
movement relative to TDRS. 

The waveform generator provides a 
forward link signal to the Harris SDR to 
demodulate and trigger the signal 
strength indicator. The pointing 
algorithm monitors the received signal 
strength and points the flight system 
antenna to follow the cart along its path. 
The cart path and planar scanar 
movement is determined to provide 
antenna slew rates expected during a 
typical TDRSS pass. 



Figure 22 - TDRS Emulator Cart and Flight 
System and Closed Loop Testing 


SUMMARY AND CONCLUSIONS 

The design, development and test of the 
CoNNeCT system represents both a 
technical and programmatic 
achievement. The NASA and Industry 
partnership in developing and integrating 


Software Defined Radios into the 
experiment is an example of the 
collaboration required for future 
missions. The technical developments; 
including demonstration of simultaneous 
waveform transmission using SDRs at 
multiple frequencies; extensive usage of 
SpaceWire data bus and issue resolution; 
closed-loop antenna tracking system 
have made significant advancements on 
an extremely tight schedule. As the 
CoNNeCT system completes 
preparations for flight, the operations 
portion of the project is developing the 
plans for experimenter proposals and 
flight operation protocols. The 
CoNNeCT system, currently on track for 
a summer 2012 launch, represents 
significant advancements of 
communications technology that will 
pave the way for future space 
communication architectures. 
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